Conversation
Documentation build overview
Show files changed (8 files in total): 📝 8 modified | ➕ 0 added | ➖ 0 deleted
|
Context: - PR #1985 added the 'Create Forecast' button to the sensor page UI - No agent existed to encode Flask/Jinja2/JS UI patterns for FlexMeasures - Patterns were worked out from scratch during the session Change: - Created .github/agents/ui-specialist.md covering: - Side-panel pattern (sidepanel-container / left-sidepanel-label hierarchy) - Permission-gating idiom: always short-circuit DB calls behind permission check - JS fetch → poll loop → Toast → reload pattern with correct status-code handling - Toast/spinner setup and teardown discipline - Disabled-button vs. hidden-panel distinction - Marshmallow data_key awareness for JS POST payloads - UI test checklist (access, permissions, data availability, boundary, not-called guard) - Known architectural debt (absent CSRF, session-expiry in poll loop, type hint gap)
Context: - PR #1985 established concrete UI patterns (side panel, JS poll loop, permission-gated view logic) that the agent system had no coverage for - A new UI Specialist agent was created to own those patterns - Coordinator roster and domain knowledge should reflect this Change: - Added UI Specialist to the agent roster (item 9) - Added 'UI Development Patterns' subsection to Domain Knowledge with: - Jinja2 side-panel template snippet - Python view short-circuit data-guard pattern - JS fetch/poll/Toast/reload skeleton - Agent responsibility table for UI-touching PRs
Signed-off-by: F.N. Claessen <claessen@seita.nl>
Signed-off-by: F.N. Claessen <claessen@seita.nl>
Signed-off-by: F.N. Claessen <claessen@seita.nl>
…nit__() missing 1 required argument: 'connection'` Signed-off-by: F.N. Claessen <claessen@seita.nl>
Signed-off-by: F.N. Claessen <claessen@seita.nl>
Signed-off-by: F.N. Claessen <claessen@seita.nl>
Signed-off-by: F.N. Claessen <claessen@seita.nl>
…docs updates Co-authored-by: Flix6x <30658763+Flix6x@users.noreply.github.com>
…d updating Signed-off-by: F.N. Claessen <claessen@seita.nl>
Signed-off-by: F.N. Claessen <claessen@seita.nl>
Signed-off-by: F.N. Claessen <claessen@seita.nl>
Signed-off-by: F.N. Claessen <claessen@seita.nl>
|
As we go though a few steps, Toast messages help the user understand that. Can somebody who has run this tell me how long the spinner is there now? Maybe until the triggering of the job has returned a success or failure? For at least that a spinner makes sense. It also seems to make sense not to allow hitting the same button for the same sensor again until the actual job outcome is in. I would go with that, actually for now. The cooldown idea is also relevant, but we need to discuss this better. Probably rate-limiting on the server is the best use of our time. (and for that we need some decisions and data modeling on account level) |
|
Sorry @joshuaunity my bad. When I read your comment, I interpreted it as a suggestion to add a spinner. I did not realize the spinner was already there. (Even though you added a screenshot, I thought this was a quick design of your own.) I now realize the spinner is already there, and to answer @nhoening, it keeps being shown until the forecasting job is done, which takes about 5 to 20 seconds or so, depending on the number of days selected. So your suggestion was rather to change the styling of the spinner. I also now see we use these bootstrap spinners elsewhere already, so I'll gladly take up your suggestion, thanks! |
Signed-off-by: F.N. Claessen <claessen@seita.nl>
|
I believe this PR also closes #1782. |
nhoening
left a comment
nhoening
left a comment
There was a problem hiding this comment.
Just a review from me testing this out, I see two issues:
First, when there is not enough data, I cannot read the text on the button very well:
Second, maybe the training period needs some tweaking?
In my example, I had uploaded two days of data, which is a week old or so. The forecasting went okay, but it forecast zeroes, maybe due to the traning period being long (Training cycle from 2026-02-09 11:15:00+01:00 to 2026-03-11 11:15:00+01:00 started ....)
The image below can illustrate it (the forecasts start 11 march). I don't think the UX around this is useful enough yet. Happy to discuss.
Finally, the button is not easy to find right now. Maybe we can ask Copilot in a follo-up PR if the sliding sidebar elements can stop taking in vertical space when they are closed.
The forecast doesn't look particularly wrong to me given the training data. Maybe test with a more complete history?
This side panels have grown over time to the point where the sensor page is vertically scrollable. I propose that we get rid of the headers on the side panels, which I find quite redundant. I think this should reduce enough vertical spacing. [update: alas, even without the headers I can still scroll the sensor page on my laptop] |
I only added two days of training data, which are non-zero. I expect the model to be trained on that, not interpolated zeroes of a one-month period around my actual data. |
Signed-off-by: F.N. Claessen <claessen@seita.nl>
|
So your expectation is that the UI automatically finds out the available data range (limited within the default training period of the last 30 days?), and selects that as the training period? I don't think our API even supports setting a training end that is different than the predict start. |
Signed-off-by: F.N. Claessen <claessen@seita.nl>
Signed-off-by: F.N. Claessen <claessen@seita.nl>
Signed-off-by: F.N. Claessen <claessen@seita.nl>
Signed-off-by: F.N. Claessen <claessen@seita.nl>
…add-forecasting-button
There was a problem hiding this comment.
Thanks for making a bit better use of the space. I still believe we should not have all this vertical space between the buttons, and I started a chatbot session to find a better way. Should be a follow-up PR.
I would address the UX / expectation problem in two ways (I know we want to keep this feature as simple as we can for now, but if users have a bad time, we should not ship it at all, or only show it to admins):
- The help text should more precisely explain what the forecaster is doing, for instance that the training window is fixed and not adjusted to available data.
- I can imagine that users often have data sets (and often in the phase when this button is interesting, they upload them), but they are not perfectly current, i.e. often there is a gap of a day or more. I suggest that the code forecasts by definition from the end of available data. We can discuss limiting that data to beliefs with horizon <= 0, and/or to add a dropdown for choosing between "forecasts start now" and "forecasts start at the end of available data")
Signed-off-by: F.N. Claessen <claessen@seita.nl>
I'll assume you mean the UI code, which is what I would choose (and not, say the API code). I'd prefer to just expand the form with a few basic customisation options, such as the ability to set your own start time. |
Signed-off-by: F.N. Claessen <claessen@seita.nl>
Okay, the forecasting API endpoint has a Options I see:
|
Signed-off-by: F.N. Claessen <claessen@seita.nl>
Signed-off-by: F.N. Claessen <claessen@seita.nl>
The datetime selector might show up differently for you, because it depends on the user's browser and locale, see https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/datetime-local. |
|
Okay, can we preset the datetime selector to the time f the last event, since it is already available, at least? I want to keep it possible for this feature that the user does not have to think a lot. |
Signed-off-by: F.N. Claessen <claessen@seita.nl>
Signed-off-by: F.N. Claessen <claessen@seita.nl>
Signed-off-by: F.N. Claessen <claessen@seita.nl>
Adds a "Create forecast" side-panel to the sensor page, letting users trigger a regression forecast with a single click — no CLI or API knowledge required.
Behaviour
FLEXMEASURES_PLANNING_HORIZONconfig) and can be adjusted up to 7 days via a duration input fieldPOST /api/v3_0/sensors/{id}/forecasts/trigger(using the selected duration, nostart→ defaults to now), pollsGET /api/v3_0/sensors/{id}/forecasts/{uuid}every 3 s, surfaces progress via Toast messages, and refreshes the chart data on success (without a full page reload)Changes
View (
ui/views/sensors.py)create-childrenpermission viauser_can_create_children(sensor)before callingget_timerange(DB short-circuit for users without permission)FLEXMEASURES_PLANNING_HORIZONfrom app config and passes the ISO string, humanized string, and integer days to the templateTemplate (
ui/templates/sensors/index.html)sidepanel-containerblock matching the style of the existing "Upload data" panelsensorsToShowUpdatedto reload chart data via the existingembedAndLoadhandler ingraphs.htmlTests (
ui/tests/test_sensor_views.py)New test file with 8 cases: page access, 404, login redirect, panel visibility per permission level (own-account user / admin / other-account user), button state at the 2-day boundary, and a mock-based guard verifying
get_timerangeis not called without permission.Documentation
documentation/views/sensors.rst— new "Creating a forecast" section with cross-reference; updated to use plain-language permissions and config-based durationdocumentation/features/forecasting.rst— new "Forecasting via the UI" subsection alongside the existing CLI and API sections; plain-language permissions, config-based default duration, and a bridge sentence directing users to the API for more controldocumentation/changelog.rst— entry addedOriginal prompt
💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.